Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix #169 - Files with very long paths fail to extract on Windows #170

Merged
merged 2 commits into from
Dec 6, 2016

Conversation

sgtcoolguy
Copy link
Contributor

Description

Uses robocopy instead of copy to be able to deal with paths over 260 characters long. Smooths out robocopy's exit codes of 0-3 to become 0 (0-3 indicate successful exits with varying meanings, but typically you'd see an exit code of 1 for a successful fresh copy) - so that chef doesn't think the copy failed under those success scenarios.

This does mean that this will not work on older Windows versions unless the user installs robocopy separately. According to https://en.wikipedia.org/wiki/Robocopy#Versions and https://technet.microsoft.com/en-us/library/cc733145(v=ws.11).aspx it's been bundled in Windows Server 2008 &2012; Windows Vista, 7, 8, 8.1, and 10. Given that range, I think it's still a relatively good choice.

Issues Resolved

Check List

…ndows

- Use robocopy instead of xcopy, alter to smooth out exit codes of 0-3 to become 0

Signed-off-by: Christopher Williams <[email protected]>
@sgtcoolguy
Copy link
Contributor Author

Just found out this still has issues due to the copying loop. It uses dir /ad /b to gather the list of files in each directory for copying. I think that the ordering here may need to be specific for it to work, because I still see errors about being unable to find output file:

==> default: STDERR: ERROR: Can not open output file : The system cannot find the path specified. : C:/Users/vagrant/AppData/Local/Temp/d20161118-4248-1jhbvnx\boost_1_62_0\libs\geometry\doc\html\geometry\reference\spatial_indexes\boost__geometry__index__rtree\rtree_parameters_type_const____indexable_getter_const____value_equal_const____allocator_type_const___.html
==> default: ---- End output of "c:\Program Files\7-Zip\7z.exe" x "C:/chef/cache/boost-1.62.0.7z" -aoa -o"C:/Users/vagrant/AppData/Local/Temp/d20161118-4248-1jhbvnx" -uy && for /f %1 in ('dir /ad /b "C:\Users\vagrant\AppData\Local\Temp\d20161118-4248-1jhbvnx"') do ("C:\Windows\System32\robocopy" "C:\Users\vagrant\AppData\Local\Temp\d20161118-4248-1jhbvnx\%1" "C:\Program Files (x86)\boost" /s /e) ^& IF %ERRORLEVEL% LEQ 3 cmd /c exit 0 ----

@sgtcoolguy
Copy link
Contributor Author

OK, narrowed it down. 7zip doesn't like the incorrect filepath separators generated by the tmpdir code for the output directory. This works:

"c:\Program Files\7-Zip\7z.exe" x "C:/chef/cache/boost-1.62.0.7z" -aoa -o"C:\Users\vagrant\AppData\Local\Temp\d20161118-4248-1jhbvnx" -uy

This doesn't:

"c:\Program Files\7-Zip\7z.exe" x "C:/chef/cache/boost-1.62.0.7z" -aoa -o"C:/Users/vagrant/AppData/Local/Temp/d20161118-4248-1jhbvnx" -uy

@sgtcoolguy
Copy link
Contributor Author

OK, pushed a fix for that. Just moved the '/' to '' substitution up a couple lines. Not sure if the wrong separators on resource.release_file will eventually matter as well? https://github.com/chef-cookbooks/ark/pull/170/files#diff-f959c0e4c1d974d03c8c9d053b695be0R62

@tas50
Copy link
Contributor

tas50 commented Dec 6, 2016

@sgtcoolguy There's a Chefspec on the path failing in Travis

@tas50 tas50 merged commit 866a595 into sous-chefs:master Dec 6, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants